home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0420.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.1 KB  |  118 lines
  1.  
  2. >>been raised specifically to the increased real line length is that
  3. >>long lines aren't safe to mail.  This problem can easily be
  4. >>circumvented by using MIME & metamail (plug plug, although I have
  5. >>nothing to do with it -- I'm just interested in seeing MIME used in
  6. >>WWW).
  7. >
  8. >If that's the case then I'd have to say that it's ridiculous to try
  9. >to fix mail (or any other transport mechanism) by mucking up HTML with
  10. >crud.  Anyway, threre are already various programs that will let you
  11. >break lines for use with mail.  Http shouldn't care at all about lines.
  12.  
  13. Amen, brother. Line length certainly should not be part
  14. of the HTML spec.
  15.  
  16. As for HTTP, the 80 character line length was, is, and always will
  17. be, merely a suggestion. HTTP implementations that assume 80 character
  18. lines are broken. But I'm sure they're out there.
  19.  
  20. >Yes, MIME would be good.  But would you make WWW pass around MIME
  21. >documents only, with HTML being one of the Content-Types, or would
  22. >you have http handle several different doc types, including both
  23. >MIME and HTML?
  24.  
  25. My strategy on integrating MIME is this:
  26.  
  27. Currently, a WWW or gopher client sends "gimme foo" and expects the
  28. server to send foo back. The client _must know_ the data format of foo
  29. in order to convey it to the user.
  30.  
  31. A gopher client knows foo's format from the first character of the
  32. MenuItem where it got foo in the first place (it assumes gopher format
  33. when foo is the empty string.)
  34.  
  35. A WWW client assumes foo's format is HTML, until it sees <PLAINTEXT>,
  36. where it switches to plain text format.
  37.  
  38. Now if we just use the name text/plain for gopher type 0, application/gopher
  39. for gopher type 1, text/html for the WWW data stream, and text/plain
  40. for the stuff after the <PLAINTEXT> tag, we begin to see how MIME
  41. fits into the picture.
  42.  
  43. I'd like to see the gopher protocol extended to include the actual MIME
  44. content-type in the Menu, like this:
  45.  
  46. 0#About This Gopher#about.txt#some.internet.host#70#text/plain
  47. 1#Departmental Publications#publications#some.internet.host#70#application/gopher
  48.  
  49. Now with text/plain and application/gopher, the MIME content-type
  50. is redundant, and not so important. But consider:
  51.  
  52. 9#My picture#connolly.gif#some.internet.host#70#image/gif
  53. 9#Pronunciation of my name#connolly.snd#some.internet.host#70#audio/basic
  54.  
  55. So in stead of registering zillions of special characters for new
  56. gopher types (i, w, M, etc.) we just add a field to the Menu item,
  57. and use type 9 for everything besides menus and text files.
  58.  
  59. The same holds for WWW references. They should include the data
  60. type, with text/html as the default. So I should be able to
  61. reference the above picture and sound in WWW:
  62.  
  63. <A HREF="gopher://some.internet.host:70/9connolly.gif"
  64.     CONTENT-TYPE="image/gif">
  65.  
  66. <A HREF="gopher://some.internet.host:70/9connolly.snd"
  67.     CONTENT-TYPE="audio/basic">
  68.  
  69. This is especially important for protocols that have no implicit data
  70. type, like FTP.  I could reference a DVI on an FTP server, and have my
  71. WWW client launch xdvi ala metamail:
  72.  
  73. <A HREF="ftp://export.lcs.mit.edu/contrib/foo.dvi"
  74.     content-type="application/x-dvi">
  75.  
  76. Now the WWW gang has always talked about format negotiation.
  77. This is where the client gives the server several options
  78. for the data format, and the server chooses between them.
  79. So what's the data type of the returned information?
  80. We need a type that's a "union" of all the data types, right?
  81.  
  82. Now we see the need for the MIME message/rfc822 content type.
  83. Consider the following scenario:
  84.  
  85. CLIENT: GET foo HTTP-Version-2 Content-Types:
  86.     1000 text/html
  87.     900 application/postscript
  88.     200 text/plain
  89.     400 application/x-dvi
  90.     100 text/x-latex
  91.     .
  92.  
  93. SERVER: 0200 Message follows:
  94. From: author@his.host
  95. Message-ID: <lasting-name-for-this-document>
  96. Subject: ... fullfills role of HTML <TITLE> element ...
  97. Mime-Version: 1.0
  98. Content-Type: application/postscript
  99. Content-Transfer-Encoding: binary
  100.  
  101. %!PS-Adobe-2.0
  102. ...
  103.  
  104.  
  105. The next possibility to consider is multimedia documents, e.g.
  106. one document that contains plain text, HTML text, gif images,
  107. sounds, etc.
  108.  
  109. That's where the MIME multipart/mixed content type comes
  110. in. If the client is prepared to receive multipart messages,
  111. this is gravy.
  112.  
  113. Get it?
  114.  
  115. Dan
  116.  
  117.  
  118.